-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable all possible leon3 bare-metal tests #33
Conversation
Hi, thanks for submitting the pull request! I ran the RTL simulation of the If the runtime of the simulation is really that long I suggest to shorten it as much as possible (e.g. do not repeat multiple times the more time consuming tests). Additionally, it would be useful to add some prints done only by CPU0, to keep track of the state of the simulation. This can be done at the granularity of each test in Thank you! |
Hi Davide, I did not run these tests in the simulator because I figured out that they take too long. Could you try running it on the FPGA and see if it actually gets stuck? It was working fine for me. Thank you! |
I tested on a Xilinx VC707 with 4 CPU tiles, but it still gets stuck with or without the new prints you added. This is the behavior I observe. What's your setup for this test?
|
Thank you. I am using the same board as you are. I do not recall which commit I ran these tests on. I'll re-do the test on the latest version and see what happens. Is you FPGA test hanging every time you run it? Does it ever get finished? |
It always hangs and according to the terminal output it's possible it's always getting stuck in the same place. |
Thank you for that info. I do not have an ESP implementation in hand and I'm compiling one as I type. However, I just ran the test with Spandex and it was working fine. Are you using ESP RTL cache or ESP SystemC cache? |
I'm actually using the RTL cache, I can try with the SystemC cache and see if there are any differences. |
I remember in the past I tested it using an ESP SystemC cache. I have never tried using ESP RTL cache but I'll give it a try now to see if anything went wrong. |
I just ran the tests with ESP RTL caches and got the same hanging behavior as yours. I'm now compiling a new design with SystemC caches. |
I ran the test with SystemC caches and got the following output.
I am afraid some other bugs are still present in the system. Just for a sanity check I will merge the HEAD of ESP into Spandex and see if it hangs or not. |
Ok, so I won't merge this pull request because the tests do not work in ESP. Anyway this is useful to potentially find a bug in the system. We'll take a look on our side to see if we find the problem. By the way are you sure about the position of |
Yes, the data_structures_setup routine calls malloc for the buffers being used by later cache_fill tests. I ran the tests with Spandex and it is working for me. How many ways in the L2 cache does your configuration have? I just realized that the "ways" parameter passed to cache_fill shouldn't be hardcoded to 4. If your configuration has more or less than 4 ways, could you rerun the modified test? Thank you! |
We reproduced the issue and some debugging showed a potential corner-case not covered correctly in the case of two consecutive We're working on a bug fix and we'll post here when done. |
Thank you for the update! Which level of cache is this bug occurring on? I'm concerned if it's on L2 then Spandex might also be affected. |
At the moment it seems it should be in the private L2. If that's the case Spandex may have the same problem, which may not manifest itself because of different timing. We'll know more once we confirm and fix the bug. |
I see. Some of the ESP L2 states are unreachable in Spandex. That's also a potential reason why it was not being triggered. |
The following multicore baremetal tests from GrLib were enabled and tested during the development of Spandex LLC at UIUC using a quad-core leon3 configuration. The enabled tests were also verified on an original ESP quad-core system. When calling base_test() from systest.c in the design folder, CPU 0 should print a report of all successfully executed tasks by each CPU.